查看原文
其他

NVMe-oF三种协议(FC、RDMA、TCP)对比:成败不只看性能

唐僧 huangliang 企业存储技术
2024-12-09

目录

-       背景杂谈:FC没死、EBOF叫好不叫座

-       性能篇:NVMe/TCP软硬Offload差别明显

-       成本和易用性:NVMe/TCP完胜了?

-       应用和扩展性:RDMA还是TCP看场景

-       安全性:FC-SP-2TLSIPsec

 

今天的分享/学习笔记主要围绕下面这份资料,跟大家聊聊存储网络方面。

 

SNIA WebcastNVMe-oF: Looking Beyond Performance Here Numbers

 

扩展阅读:《NVMe-oF 1.1规范:多路径、非对称命名空间和NVMe/TCP

 

背景杂谈:FC没死、EBOF叫好不叫座

 

从一个异构的“世界”转变为另一个(注:本文中图片均可点开放大

 

NVMe-oF的目标是未来存储Fabric互连的霸主,想替代现有的Fibre Channel(光纤通道)、iSCSIFCoE(实际上没普及就淡出了)三种SAN块存储协议。

 

-       FC-NVMe可以跑在当前主流的FC网络基础设施(交换机和HBA卡)上,与传统FCP(即SCSI协议)共存。设计用于存储阵列的前端主机连接协议,更多针对关键业务应用。

 

-       NVMe/TCP我在《NVMe over TCP:iSCSI的接班人?》曾有过介绍;NVMe/RoCE或者IB则是跑在无损的RDMA网络上,已经有一部分全闪存阵列开始支持,它当前的应用范围更广一些。

 

-       RoCETCPiWARP也能用在HCI超融合系统中,比如VMware vSAN和微软的AzureStack(其存储技术曾命名为S2D)。特别是后者较早支持RDMA以太网,在性能上有较大获益(参见Sean高翔老师在2017年支持的项目4节点近160IOPSSDS/超融合测试不能只看数字》)。

 

关于“FC已死”的言论很早就有人提过,以太网阵营的iSCSI没能成为“掘墓人”是因为性能和稳定性方面还有些达不到关键业务的要求;FCoE的问题我想留在下文中讨论;如今NVMe/RoCEIB的性能已经不是问题,而我们也看到FC-NVMe正在延续光纤通道的生命力。

 

上图引用自Cavium(收购了QLogic,后来又被Marvell收购)一份几年前的资料。FC-NVMe能够使用SCSTSPDK分别支持内核态和用户态驱动,目前我听到用SPDK来连接“新FC协议”存储阵列的实例还不多。

 

三种新的NVMe-oF协议在应用中存在一些重叠的地方。右半边偏向关键业务应用,左边则针对高性能用例;FC-NVMeNVMe/TCP主要针对通用场景,而NVMe/RoCE or IB则有一部分针对特定场景——比如互联网/云计算服务商、HPC(高性能计算)、机器学习,用于HCI的互连或者连接EBOF(以太网BOF)扩展SSD访问等。

 

Oracle数据库这样的关键业务还是青睐稳健的FC-NVMe

 

我在NVMe/TCP的应用中也看到了EBOF——从当前来看EBOF在商业市场中有些叫好不叫座,目前主要有Pure  Storage等存储阵列用于后端SSD扩展,比如《NVMeF的另一种用法:连接AFA控制器和JBOF》里面写的就是EBOF。而几年前Facebook OCP提到过Marvell转接SSD方案,也只是说找了AcctonFoxconn两家ODM合作之后就没更多公开消息了。


转接NVMe SSD25Gb以太网的NVMe-oF——EFOF究竟适合通用市场还是定制需求呢?

 

NVMe-oF E-JBOF设计解析:WD RapidFlex网卡 & OpenFlex Data24》我曾经觉得不错,但听说这款产品没能继续做下去。

 

除此之外EBOF只看到几家小厂公开在做。像《NVMe over Ethernet:又一家FPGA互连闪存的Apeiron》这家5年前还在使用私有协议的先行者,如今也不知情况怎样了。

 

性能篇:NVMe/TCP软硬Offload差别明显



SNIA这份资料中,将分别从性能、成本、操作简化性、应用、扩展性和安全角度来讨论NVMe over Fabric。首先从性能谈起:

 

上面图表对比的是单链路32GbFC25GbE TCPRoCE这里写的可能不全面,更多见下图)。我们看到随着并发线程的增加,传统光纤通道4KB随机写IOPS只能达到20,这应该与SCSI协议有关;而NVMe-oF则跑到了接近80,这个效率可以匹配PCIe 3.0 x4 NVMe SSD的最高性能了。

 

并发线程数10-100这个区间,是被重点关注的部分

 

这时把多种NVMe-oF协议加进来才有意思。我们看到纯软件实现的NVMe/TCP表现相对较差,128并发线程才跑到最大性能;FC-NVMe的峰值IOPS更高一些是因为32G对比25G的网络优势;硬件卸载的TCP-OffloadRoCE则互有胜负。

 

对比延时,传统FC存储网络从理论上也是完败。比如在单一链路并发线程达到100时会超过500µs,而实际应用中大多是多路径,对业务性能影响又是另一种情况了吧。

 

不同NVMe-oF协议的延时对比主要看低并发/队列深度时。纯软件NVMe/TCP接近100微秒了;而RoCE只有大约30微秒;FC-NVMe50微秒左右TCP-Offload甚至比它还要稍好一些。

 

上面图表对比的是:发起端主机平均每个百分比CPU开销能跑出的I/ONVMe/RDMA RoCE在并发线程10以内时表现较好;而NVMe/TCP Offload反而是在16线程以后效率不断提高;软件实现NVMe/TCP在超过128线程以后效率显著下降。

 

如果按照每1% CPU能跑1000 IOPS计算,那么100%就是10IOPS,我理解这是单个Core在内核态的表现。

 

成本和易用性:NVMe/TCP完胜了?

 

如上表:传统意义上认为FC-NVMe针对集中化闪存阵列而不是软件定义存储,不过也有些存储系统加入了NVMe/RoCE的支持,而NVMe/TCP则有着替代iSCSI的前景。

 

从成本上来看,FC-NVMe可能没有优势。不过我们不应只对比硬件成本,而不考虑SDS的软件和运维开销

 

不知这份资料是否站在对NVMe/TCP有利的立场?“边缘/分布式系统扩展”和“云运维模型/自动化”这2项都被列为它的优势所在,这大概是因为TCP协议的优势(其实同时也有劣势),更适合跨数据中心广域传输,并且容错方面比UDP以太网和FC网络要强。

 

这里只是对比RoCETCP/IP

 

-       性能:还是RoCE更胜一筹;

-       互操作性TCP/IP最好,因为对交换机几乎没有要求,而RoCE正在改善;

-       交互测试成本TCP/IP评价为“中等”;而RoCEFC一样高昂;

-       网络拥塞影响TCP/IP中等,可预期;RoCE可见,但不可预期;

-       网络管理影响TCP/IP只是常规操作的一部分;RoCE作为新协议,失去了一些端到端功能。

 

初始配置步骤,NVMe/RoCE总体上相对最复杂

 

上表是对比不同类型Fabric互连的初始化配置步骤。

 

-       主机端步骤FCFC-NVMe只有2步,我理解就是把HBA卡驱动装好,多路径在这里不知算不算必需步骤;NVMe/TCPNVMe/RoCE以前要麻烦一些,而现在也简化了。

 

-       网络步骤FCFC-NVMe5步(居中),划Zone啥的都是基本操作;NVMe/TCP只要3,对以太网交换机的改动较少;而RoCE在这里要7步,牵涉到RDMADCB无损以太网会麻烦一些

-        

-       存储端步骤FCFC-NVMe都是7NVMe/TCPNVMe/RoCE要增加一点。

 

额外附加这个图表算是怀旧吧:)FCoE就是输在了对网络的要求和操作复杂性上。不过我觉得从iSCSI部分来看可能有点夸张——Windows下用Initiator连接存储不算难吧?

 

应用和扩展性:RDMA还是TCP看场景

 

上图所指的“Scale Out后端”,就是RoCEIB网络连接的JBOFEBOF),右边机框里面的CPU应该只是管理用途而不在数据路径上。

 

左边可以是服务器(软件定义存储)或者阵列控制器,这个架构类似我在前面提到过的PureStorage。其实25GbE的带宽并不比12Gb SASMultilane x4)更快,只是以太网有更高速率的潜力(只要不惜成本),另一方面就是NVMe SSD后端也没法像SAS盘那样使用JBOD了。其实还是PowerMax高端阵列那样的PCIe Switch直连SSD性能效率最高,但局部扩展性和灵活性不如以太网,还是要看场景。

 

这个图表是2RDMA网络的延时对比,InfiniBand效率高是正常的,不过左边没有交换机直连情况下这个差距相对较小,而右边加入交换机则会增大。除了HPC以及高端存储的控制器间互连之外,对IB有强依赖的应用不多。

 

经典SAN架构

 

还记得在网络磁盘阵列刚开始流行那些年,我觉得能做FC双控的厂商就挺厉害的,那时还没听说过SSD。时过境迁,如今传统存储价值更多体现在R.A.S.(可靠性、可用性、可服务性)和成熟度上。

 

上面图表是iSCSINVMe-oF25GbE网络下的对比。吞吐量方面,iSCSI甚至不太容易充分发挥25G网络了;而延时显然也是RoCE处于优势。可惜iSER没有大规模标准化。

 

这里讲的故事是计算存储解耦合。在Rack Scale层面,NVMe-oF/RoCE可以达到接近本地磁盘(SSD)的性能;而是否使用NVMe/TCP则依赖于对性能的需求。

 

关于超融合和Scale-Out存储,我在本文开头聊过了。

 

GPUDirectStorageGPU直连存储)也需要RDMA网络,这样才能从绕过ReceiveTransmit端的CPU,以远程直接内存访问的方式,读写操作EBOFSSDCMB缓存。

 

Fabric互连的扩展性来看:

 

-       左边的机架内部/小规模扩展GPU节点和存储阵列(通常是NAS)之间,NVMe/RoCE or IB就挺好;

 

-       中间和右边为跨机架互连/较大的集群,计算节点和存储控制器之间可以是NVMe/TCP/RoCE/FC,有一处区别就是阵列直连JBOF还是通过NVMe-oF网络连接“EBOF”;

 

-       最上面到远程数据中心的连接,只有NVMe/TCP支持了。

 

举个例子吧,Dell EMCPowerStoreOS 2.0存储控制器软件更新中,加入了NVMe over FC支持。看来端到端NVMe支持应该是未来新型全闪存阵列的标配了。

 

安全性:FC-SP-2TLSIPsec

 

由于潜在的数据中心安全威胁,支持对静态和传输中的NVMe数据加固(加密保护)十分重要。

 

如上图,为了身份验证、数据完整性和安全加密,有几种针对不同协议的保护技术:

 

-       FC-SP-2:在传统FC协议2112 byte数据包Payload的头部拿出32字节用于ESP Header,尾部16字节+Pad用于ESP Trailer

 

-       TLSTransportLayer Security):NVMe/TCP已经支持,许多网卡能提供完整卸载加速;

 

-       IPsecNVMe/TCPNVMe-oF RoCE已经支持,许多网卡能提供完整卸载加速。

 

就写到这里吧,看来安全性部分还是FC-NVMe更胜一筹。

 


参考资料  https://www.snia.org/sites/default/files/ESF/NVMe-oF-Beyond-Hero-Performance-Numbers.pdf

 


扩展阅读:企业存储技术》文章分类索引(微信公众号专辑)


:本文只代表作者个人观点,与任何组织机构无关,如有错误和不足之处欢迎在留言中批评指正。90834312。如果您想在这个公众号上分享自己的技术干货,也欢迎联系我:)

尊重知识,转载时请保留全文,并包括本行及如下二维码。感谢您的阅读和支持!《企业存储技术》微信公众号:HL_Storage

长按二维码可直接识别关注


历史文章汇总:http://www.toutiao.com/c/user/5821930387/

http://www.zhihu.com/column/huangliang



点击下方“阅读原文”,查看更多历史文章

↓↓↓

修改于
继续滑动看下一个
企业存储技术
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存